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(54) Apparatus for processing data 

(57) Apparatus for processing data relating to the transfer of funds between accounts comprises a computer system 
including a payments router (103), the central processor of which is arranged to receive a payment instruction and to carry 

ut a sequence of steps in which the source and destination of each payment are identified, and parts of each payment 
instruction are reformatted into a format acceptable to the computer system concerned to generate an account enquiry 
validating the beneficiary account particulars, an enquiry as to the sufficiency of funds in the source account, and the debit 
and credit instructions for the source and beneficiary accounts. Provision may be made for operator intervention. All 
transactions may be recorded in a transaction log file to provide a complete audit trail. 




I07 



- Jj« |'8_ 



PAYMENT 
ROUTER 
15 12 



-103 




I ON-LINE | 
L"K , 



FIG. I 



o 

TO 

ro 

no 
cn 

CD 
CO 

oo 



1/2 



FUNDS • J/H06 

TRANSFER 



CUSTOMER 
PC A 



r 



102 



7 




COMMS. 
PC 



1 


2 


3 


e J21 


1 









22 



\04 



20 



101 



BALANCE 
a DETAIL 





INTERFACE 


^105 ^ 




PC 


_ J§ ^10 jjl |»8 _ 










PAYMENT 
ROUTER 
15 12 


^-1 03 



BRANCH 
ADVICE 




ON-LINE I 
LMH I 



107 



FIG/I 



2/2 

A 



205 



INQUIRY 
TEMPLATE) 
STORE 



208 



DEBIT 
ENTRY 
FORMATS 



209 



CREDIT 
ENTRY 
FORMATS 



BUFFER 



CPU 



202 



TRANSACTION 
LOG 
FILE 



203 



£ 



207 



CONSOLE 



COMMS. 
INTER- 
FACE 



206 




210 



FIG.2 



- 1 - 



2251093 



APPARATUS FOR PROCESSING DATA 



The invention relates to apparatus for 
processing data relating to the transfer of funds 
between accounts. 

The invention is concerned with a computer 
system designed to carry out transactions comprising the 
transfer of funds between bank accounts. The banking 
group using the system may extend over several 
countries , and accounts may be of different types and in 
different currencies . 

The banks and branches within the banking group 
using the system may use different computers for their 
accounting. Transfers of funds will have to be made to 
banks outside the group, who will generally also use 
different data formats for the transmission of 
accounting information. The system of the invention 
therefore includes means for storing the message format 
requirements of each destination address, and also 
routing information. For example, it may be necessary 
for funds to be transferred to some overseas banks by 
mail or by telegraphic transfer, whereas others can 
accept direct electronic transfer instructions. 



Transfers of funds may take place between 
accounts within the same branch of a bank, between 
different branches of the same bank, between different 
banks in the same country , or between banks in different 
countries . 

It may be convenient for some transfers to be 
processed on-line, while others of lower urgency, or 
concerning future payments , are assembled into batch 
files and are processed after the close of each working 
day. 

As in all banking matters, the system of the 
invention is designed to provide a high level of 
security. Data may be encrypted for transmission, 
access to the system may be limited by passwords of 
different security levels, transactions of an unusual 
nature or amount may be reported for manual 
verification, and limits may be placed on the sums 
transferred, or the accounts from which they are to be 
drawn or to which they are to be credited. Payment 
instructions may be validated in respect of the 
account-holders name, account number, the branch in 
which the account is held, and any limits which may have 
been imposed on the amounts to be transferred. 
Customers may be required to input a personal 
identification number. Check digits may be used to 
detect and/or correct errors arising in data during 
transmission, or from errors in data entry. Certain of 
these methods are well known and will not necessarily be 
specifically mentioned below in describing the 
invention. 



An essential feature of the system of the 
invention is that it should produce adequate transaction 
records , so that the customer has confirmation, first, 
that his instructions have been received, validated and 
accepted, and then that the transaction has been duly 
carried out in accordance with his wishes. The system 
must keep a log of every stage of each transaction for 
audit purposes. 

It is an object of the present invention to 
provide apparatus for processing data, and in particular 
for transferring funds between bank accounts, which is 
designed to meet the above requirements. 

The invention will now be further described with 
reference to the accompanying drawings, in which 

Figure 1 is a schematic block diagram of the 
system, and 

Figure 2 is a diagram of that part of the system 
which is concerned with the generation and routing of 
payment instructions. 

Referring first to Figure 1 , the major 
components of the system are shown schematically in 
block diagram form, with the flow of information between 
the items represented by the blocks being indicated by 
numbered arrows. 

The system consists, in outline, of a hub, 101 f 
which receives an input from a customer's computer , 102, 
validates and acknowledges the input, reformats it as 
necessary, and transmits it to a payments router 103, 
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which will be located in the chief office of the bank. 
The payment router analyses the input, determines the 
route for making the payment, generates the payment 
instructions, receives confirmation that the payment has 
5 been effected, transmits confirmation to the hub, and 

generates advice notes, reports, transaction logs, and 
any error messages or requests for manual intervention 
that may be necessary. 

The system will now be described in more detail. 
The hub, 101, will be installed at a central site 
adjacent to the bank's main computers. It comprises a 
number of computers connected in a network. Generally 
there will be at least four such computers, one or more, 
such as 104, being dedicated to communication with the 
customers' computers and so receiving the initial input 
data, another, 105, acting as an interface for 
communication with the payment router, another, the 
funds transfer computer 106, validating and storing the 
input messages for onward transmission, and a further 
one at least, 107, being reserved for holding the 
customer accounts and maintaining records of their 
balances and operating details. 

Payment instructions to the bank are prepared 
and verified by the customer on his computer 102 on his 
25 own premises, and may be assembled into a batch file to 

be stored until released by an authorised official for 
transmission to the bank. Transmission may be over the 
normal telephone system, or a dedicated data line may be 
installed. As is customary in data transmission, 
30 error-correcting codes will normally be employed, and 

the data may be encrypted before transmission and 
decrypted on receipt. 
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The steps involved in carrying out a typical 
transfer of funds using the system of the invention will 
now be described, each step in the process being 
indicated by a correspondingly-numbered arrow-head in 
Figure 1 . 

Initially it will be assumed that the customer 
has entered particulars of all the funds transfers he 
wishes to initiate into a batch file in his computer 102 
for transmission when authorised by an official of the 
company . 

1 . An authorised official at the customer site 

verifies the payment requests and authorises 
their release to the bank. To release a payment 
request the official must be in possession of a 
key disk, which permits release, and which 
provides the unique encryption key for 
encrypting that customer's messages. This 
process initiates the communications link 
between the customer's site and the 
communications computer 104 of the hub. After 
initial handshaking the following take place: 

2. The customer requests any outstanding 

transaction serial numbers confirming receipt of 
previous transaction files. 

3 * If such exist, the hub communications computer 

104- transmits them back to the customer, 

4. The batch file which the customer has prepared 

is now transmitted to the hub 101, where it is 



received in the communications computer 104. 
This computer adds a transaction serial number 
to each entry , and a status field which will be 
repeatedly updated as the transaction is 
processed through the system. 

The file is now sent to the funds transfer 
computer 106, where it is validated for internal 
consistency, and checked to ensure that it 
conforms to any instructions held by the bank 
relating to the management of the account. 

Error messages are generated in the computer 106 
for any item which fails the validation, and the 
status field is suitably updated. The 
transaction numbers and status fields are 
returned to the communications computer 104. 

If the customer is still on line the transaction 
numbers and any error messages are transmitted 
back to his computer 102. If not, they are 
assembled into a batch file for transmission to 
him on the next occasion on which he establishes 
contact. 

The interface computer 105 continually polls the 
funds transfer computer 106 for further funds 
transfer instructions. As it receives them it 
re-formats them into a standard format for 
transmission, and assembles them into a file for 
transfer to the payments router 103, 



The interface computer 105 establishes contact 
with the payments router 103. After the initial 
handshaking steps the interface computer 
requests any outstanding confirmations, these 
representing successful transfers of funds 
initiated by the previous contact. 

The outstanding confirmations are downloaded 
into the interface computer, where they are 
stored. 

The new instructions held in the interface 
computer 105 are transmitted to the payments 
router 103. 

The payments router 103 checks the destination 
account nominated in the payment instruction to 
ensure, in the case of an internal account, that 
the account exists, and, in the case of an 
external account, that it is a valid 
destination. The router then identifies the 
system which carries the account to be debited, 
and then queries that account to establish the 
availability of funds to cover the payment. 

Payment instructions are generated by the 
payments router. The payment format is dictated 
by the destination account and the associated 
transmission system. The payment may be sent 
internally to one of the bank's own computers, 
via the S.W.I.F.T. network to an external bank, 
or filed for inclusion in the end-of-day 
internal or inter-bank processes. 

If funds are not available , no payment 
instructions are generated. 
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14. A response is sent to the hub from the payments 
router indicating whether or not the payment has 
been successfully carried out. 

15. The payments router generates a confirmation for 
5 each of the urgent payments (i.e. those 

requiring to be acted on immediately) that has 
been carried out successfully. 

16. The payments router generates branch advices 
advising each branch of any transfers relating 

10 to their customers that have been made on line. 

17. Instructions are prepared by the payments router 
for any inter-bank payment which could not be 
made electronically. 

18. The confirmations of successful payments , and 
1 5 messages relating to failed payments are 

assembled into a file and downloaded directly to 
the interface computer 105. 

1 9 . The information held in the interface computer 

105 is now used to update the database held in 
20 the funds transfer computer 106 by updating th 

status fields. 

20. The interface computer 105 generates a file of 

confirmations and passes it to the 
communications computer 104. 

25 21 . The customer is now able to call up the hub and 

confirm whether payments have been made. 



22. The communications computer 104 passes to the 

customer's computer a list of confirmations 
confirming the payments that have been made, 
together with any error messages that have been 
generated . 

The functioning of the payments router 103 will 
now be described in more detail with reference to Figure 
2. 

When a payment instruction is received from the 
hub 101 it is stored in a buffer register 201. This 
holds, in addition to various status flags and keys 
associated with the instruction, the identification of 
the source account and destination account, the amount 
and currency to be transferred and the effective date of 
the transfer. The central processing unit 202 of the 
payments router allocates a confirmation status to the 
instruction and re-transmits it to the hub as 
confirmation that the instruction has been received. At 
the same time an entry is made in a transaction log file 
203. This file receives an entry for every message, 
transaction and action taken by the payments router, 
thereby providing a complete audit trail. 

Next, the payment instruction is analysed to 
determine the type of payment, which will determine the 
action to be taken. It may require an urgent payment to 
be acted on immediately, or a normal payment to be 
processed overnight by the normal Electronic Money 
Transfer system at end-of-day. 
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If the payment instruction is for an immediate 
payment , the central processing unit 202 next 
interrogates the portion of the instruction which 
identifies the destination account for the payment, and 
5 calls up an inquiry template from an inquiry template 

store 205* This template is used to reformat part of the 
payment instruction into a format acceptable to the 
computer system of the beneficiary's account as an 
account enquiry, and it is then transmitted via a 
10 communications interface 206 to that system by way of an 

inquiry as to whether the account details are correct. 

Assuming that the credit account exists, the 
central processing unit 202 next calls up a further 
template from a debit entry template store 208 which 
15 formats the debit portion of the instruction into a form 

which the system of the payer's account will accept as 
an instruction to debit the account. This instruction is 
then transmitted to that system. 

If funds are insufficient the information is 
20 displayed on an operator's console 207, where a decision 

is made either to reject the transaction, in which case 
a message is passed back via the hub, or to allow it to 
proceed. Each message or transaction is, of course, 
recorded in the transaction log file 203 to ensure that 
25 the audit trail is complete. 

The credit portion of the instruction must now 
be processed, and first it is examined to determine 
where the destination account lies. It may be in the 
same branch of the bank as the source account, in a 
30 different branch of the same bank, in a different bank, 



which generally will have a different computer system 
and will require its instructions in a format 
recognisable by that system, or in an overseas bank 
which will also require also a currency conversion to be 
carried out, and which may call for special methods of 
payment, such as mail or telegraphic transfer of funds. 

The central processing unit 202 now interrogates 
the payment instruction and calls up the appropriate 
credit entry format from a credit entry format store 
209 . This takes account of any currency conversions 
that may be required and the need for any special method 
of payment, and the credit instruction is formulated 
accordingly. According to the circumstances the credit 
instruction may be transmitted directly to the computer 
system of the destination account, (internal payment), 
stored in a batch file 210 for onward transmission at 
the close of the working day, formulated as a 
telegraphic transfer and sent to the destination bank, 
or routed to an operator for the preparation of a mail 
transfer. 

At each of the steps described above an entry is 
made in the transaction log file 203, so that a complete 
record exists which provides an audit trail , and which 
also provides a means of tracking any error or 
malfunction which may occur in the system. 

All normal messages (value date 2 days hence) 
are grouped , together in a batch file 210 for input at 
end-of-day into the bank's overnight processing. 



CLAIMS 



1 . Apparatus for processing data relating to the 

transfer of funds between accounts and comprising a 
computer system including a payments router (103), the 
payments router including a central processor (202), an 
enguiry template , store (205), a debit entry template 
store (208), and a credit entry format store (209), and 
in which the central processor is arranged to receive a 
payment instruction and to 



a) examine the destination field of the instruction 
to identify the destination account for the 
payment, 



b) call up the appropriate inguiry template from 
the inguiry template store and therewith to 
reformat part of the payment instruction into a 
format acceptable to the computer system of the 
beneficiary's account as an account enguiry, 

c) transmit the enguiry to that system to confirm 
that the destination is a valid one, 

d) examine the source field of the instruction to 
identify the payer's account, 

e) call up the appropriate inguiry template from 
the inguiry template store and therewith to 
reformat part of the payment instruction into a 
format acceptable to the computer system of the 
source account and transmit it as an enguiry as 
to whether there are sufficient funds in the 
account to meet the payment, 



f) on such confirmation to call up a further 
template from the debit entry template store and 
therewith format the debit portion of the 
instruction into a form which the system of the 
payer's account will accept as an instruction to 
debit the account, 

g) transmit the formatted instruction to that 
system, 

h) call up the credit entry format appropriate to 
the destination account from the credit entry 
format store, 

i) formulate the credit portion of the instruction 
in accordance with the credit entry format for 
transmittal or further processing. 

2. Apparatus according to claim 1 in which the central 
processor is further arranged, on identifying a failure 
of confirmation in step c) or step e), thereupon to 
produce a message at an operator console, and to accept 
a further instruction entered at the console. 

3. Apparatus according to claim 1 or claim 2 in which 
the central processor is further arranged to identify 
all normal messages (i.e. those having a value date two 
days ahead) and store them in a batch file for input at 
end-of-day into the bank's overnight processing. 

4. Apparatus according to any preceding claim including 
means for generating and storing a transaction log file 
in which the central processor records each message or 
transaction to provide a complete audit trail. 
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5. Apparatus for processing data relating to the 
transfer of funds between accounts and comprising a 
computer system including a payments router organised 
and arranged to operate substantially as indicated 
5 schematically in and as herein described with reference 

to the accompanying drawings. 
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